The present invention relates generally to communications systems and, in particular, to techniques that provide for synchronizing databases, such as a database containing a phonebook stored in a subscriber identity module (SIM) of a mobile terminal used in a cellular radiocommunication system with a corresponding database in a personal computer (PC).
The cellular telephone industry has made phenomenal strides in commercial operations in the United States as well as the rest of the world. Growth in major metropolitan areas has far exceeded expectations and is rapidly outstripping system capacity. If this trend continues, the effects of this industry""s growth will soon reach even the smallest markets. Innovative solutions are required to meet these increasing capacity needs as well as to maintain high quality service and avoid rising prices.
One recognized trend is the convergence of the so-called information industry, as symbolized by the evolution of the personal computer (PC), and the so-called communications industry, as symbolized by the evolution of the mobile phone. Both types of devices are characterized by rapidly increasing performance (hardware) and by increased application (software) capabilities. In the near future, it is likely that mobile phones will communicate more directly with other information devices, such as the PC, to exchange information. Many subscribers of wireless services also own personal computers and, as each type of device gets more sophisticated in its data handling capability, may wish to exchange data therebetween, for example, between databases (such as phone books), stored in each device.
Consider the example illustrated in FIG. 1. Therein, a PC 10 and a mobile phone 20 are linked together via a communication link 30. The communication link 30 may be either a wire or wireless (e.g., infrared) link. It will be appreciated by those skilled in the art that, while a PC and mobile phone are used as examples of two devices between which database synchronization may be performed, the present invention is not limited to these two types of devices and may, in fact be applied to database synchronization between any two types of devices, such as electronic organizers, pagers, and the like. The PC 10 includes a database 40, for example, containing phone records or a calendar, while the mobile phone 20 includes a corresponding database stored on its subscriber identity module (SIM) card 50. As will be appreciated by those skilled in the radiocommunication arts, the SIM card 50 is a removable smart card that was created for the GSM radiocommunication standard as a mechanism for conveniently grouping and storing information elements related to the mobile subscriber in a removable manner, which card is insertably removable from mobile phones. The term xe2x80x9csynchronizexe2x80x9d, as it is used herein to refer to database operations associated with two or more devices, means changing the contents of one database so that it matches, or xe2x80x9cmirrorsxe2x80x9d, the contents of the other database.
Conventionally, to synchronize the database 40 and the database stored on the SIM card 50, it was necessary to individually compare each record in each database. For example, the database of phonebook records stored in the SIM card 50 could be transmitted to the PC 10 via link 30. Then, the records in each database could be compared and updated such that the two databases mirrored one another. For example, changes associated with records found in the database 40 but not found in the version of the database transmitted from the mobile phone 20 to the PC 10 could be relayed back to the mobile phone 20 to update the database stored in the SIM card 50. This synchronization process (sometimes alternatively referred to as xe2x80x9cfull synchronizationxe2x80x9d or xe2x80x9cslow synchronizationxe2x80x9d) is complicated and time consuming. For example, just to identify what changes had been made to the SIM card""s database often requires that the PC 10 compare a most-recently received version with a previously stored version.
To address this problem, a change log has been added to the devices as shown in FIG. 2. The change log contains information regarding records which have been operated upon in either database subsequent to synchronization therebetween. The change log also records the time at which a synchronization operation was last performed between two databases, so that changes made prior to a previous update can be ignored. The change log can be implemented, for example, in a portion of memory which records for each change an event (e.g., add, delete or modify), the identity of the database record for which the event occurred and a timestamp indicating when the event took place. For example, if a phone record is added to the database 40 in PC 10 subsequent to it being synchronized with the SIM 50 in mobile phone 20, then an indication of such is added to the change log 200. Likewise, if the subscriber associated with the mobile phone 20 (and SIM card 50) deletes a record in his or her phonebook, then this change will be reflected in the change log 210. Moreover, if the change log is empty, then no changes need to be made to the database 40 in the PC 10. Using change logs 200 and 210 may be advantageous during synchronization since only those records which have been modified, added or deleted (as recorded in the change log) since the last synchronization update need to be transmitted between the devices. Thus, the synchronization process may be performed more rapidly and this process has, therefore, been referred to as xe2x80x9cfast synchronizationxe2x80x9d.
Under certain circumstances, however, it may still be desirable to perform full (i.e., slow) synchronization of corresponding databases in two devices even when change logs have been implemented to enable fast synchronization. For example, if a user resets or erases his or her calendar database in a mobile phone, such an action may dictate that a full synchronization be performed between the two databases, that is, the large number of changes results in there being no particular advantage in such cases to using the change logs 200 and 210 to accomplish synchronization. Invoking full synchronization of two databases when fast synchronization is available has been accomplished by, for example, randomly or incrementally changing the value of a database identifier (DID) which is passed between the devices as part of the synchronization process. The change in DID values acts as a signal that tells the device performing database synchronization to use full synchronization instead of fast synchronization. The receiving device, (e.g., a PC) compares the DID received from the other device (e.g., a mobile phone) with a DID that it previously stored. If they are the same, then fast synchronization will be used. If they are different, then full synchronization is performed.
Unfortunately, although it may speed up the synchronization process, adding the change logs introduces another problem. More particularly, fast synchronization relies on the use of a time stamp associated with each entry in the change log 200, 210. The time stamp indicates what time a particular change was made. When a change log associated with one database (e.g., the change log 210 associated with the SIM 50) is supplied to the other device (e.g., the PC 10), the synchronization engine (not shown) within the other device uses the timestamp to resolve potential conflicts that can occur when one modification has been made to an entry in one of the databases and a different modification has been made to the same entry but in the other database. In such cases, the rule is to assume that the most recently made change is the correct one. For example, consider the situation in which there exists a record xe2x80x9cAxe2x80x9d in each of two devices (denoted xe2x80x9cdevice 1xe2x80x9d and xe2x80x9cdevice 2xe2x80x9d) when databases in each of the devices have been synchronized with one another. Subsequent to synchronization, assume that on device 1 the record A is deleted at 12:34, while on device 2 the same record is modified at 12:40. The next time that the devices 1 and 2 are synchronized with one another, the synchronization procedure will detect that the same record has been deleted on one side and modified on the other. Taking the rule that the most recent modification is the correct one, the modification to record A that was performed on device 2 will be retained by copying it over to device 1. The two devices are now synchronized again.
It can be seen that, because the timestamps play such an important role in the synchronization process, that the timers in the devices need to be very accurate, aligned with one another, and unchanged. This is not always the case in mobile devices, however. It is quite common for the user of a mobile device to travel to another time zone and therefore, change the time on the device""s clock. This can cause problems with synchronization, however, because if the user""s timer is made to move forward or backward, it is possible for a recent change to a database to incorrectly appear to have taken place prior to the previous synchronization operation. As a result, that change would be ignored in the synchronization effort, effectively losing the change.
FIGS. 3 and 4 illustrate some scenarios in which changing the clock on a device can cause erroneous results to occur when a subsequent database synchronization operation is performed. Referring first to FIG. 3, this timing diagram shows clocks and events in each of two devices, denoted xe2x80x9cDevice 1xe2x80x9d and xe2x80x9cDevice 2xe2x80x9d. At time T1, the clocks in both devices read xe2x80x9c1:00pmxe2x80x9d, at which time a fast database synchronization operation is performed. As mentioned earlier, this causes, among other things, the time of synchronization to be recorded in the change log 200. Sometime later, at a time denoted T2, the clock in Device 1 has been set back, so that it now reads 12:00pm (i.e., a time earlier than 1:00pm). This may have been done, for example, to account for travel through one or more time zones. At this time T2, a record xe2x80x9cAxe2x80x9d in Device 1""s database is changed. This change is recorded in the change log 200, along with a timestamp=12:00pm, indicating the time of the change. At a subsequently later time, denoted time T3, the clock in Device 1 indicates 8:00pm, and the clock in Device 2 indicates 9:00pm. At this time, T3, another fast database synchronization operation is performed between the respective databases in Device 1 and Device 2. As part of this synchronization operation, the synchronization engine looks at the timestamps in the change log 200, and ignores all changes that appear to have taken place prior to the previous synchronization operation (which took place at time T3). As a result, the change to record xe2x80x9cAxe2x80x9d, which actually took place at time T2, appears to have occurred prior to time T1 (i.e., the time of the previous synchronization operation). Accordingly, the change to record xe2x80x9cAxe2x80x9d that was made at time T2 is ignored in the synchronization operation, effectively losing it. It will be observed that even if the clock in Device 1 had been moved ahead one hour at some point between time T2 and T3, so that at time T3 the clocks in Devices 1 and 2 both read 9:00pm, the change made to record xe2x80x9cAxe2x80x9d in Device 1 at time T2 will be lost in the synchronization operation.
FIG. 4 illustrates another scenario in which changing the clock on a device can cause erroneous results to occur when a subsequent database synchronization operation is performed. Here, this timing diagram shows clocks and events in each of two devices, denoted xe2x80x9cDevice 1xe2x80x9d and xe2x80x9cDevice 2xe2x80x9d. At time T1, the clocks in both devices read xe2x80x9c1:00pmxe2x80x9d, at which time a fast database synchronization operation is performed. As mentioned earlier, this causes, among other things, the time of synchronization to be recorded in the change log 200. The value of the clock in Device 1 is subsequently moved forward, so that at time T2, it reads 3:00pm while the clock in Device 2 only reads xe2x80x9c2:00pmxe2x80x9d. At this time T2, a record xe2x80x9cAxe2x80x9d in the Device 1""s database is changed. This change is recorded in the change log 200, along with a timestamp=3:00pm, indicating the time of the change. Subsequently, the clock in Device 1 is again changed, this time backward, so that at a time denoted T3, it and the clock in Device 2 both read 2:30pm. At this time T3, a fast synchronization operation is again performed between the databases in Device 1 and Device 2. However, because the timestamp associated with the change to record xe2x80x9cAxe2x80x9d at time T2 indicates that the change took place at 3:00pm (i.e., a time later than the present time of 2:30pm), the change to record xe2x80x9cAxe2x80x9d is ignored in the synchronization operation, effectively losing this data.
It is possible to construct still other examples in which a change to a clock causes a fast synchronization operation to effectively lose one or more changes to records in the database.
Accordingly, it would be desirable to provide techniques and apparatuses that enable the usage of change logs for synchronizing databases, but also accommodate the movement of portable devices across time zones.
It should be emphasized that the terms xe2x80x9ccomprisesxe2x80x9d and xe2x80x9ccomprisingxe2x80x9d, when used in this specification, are taken to specify the presence of stated features, integers, steps or components; but the use of these terms does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.
In accordance with one aspect of the present invention, the foregoing and other objects are achieved in methods, apparatuses and computer readable storage media that synchronize a first database with a second database, wherein the first database is located in a mobile terminal. Synchronization comprises setting an indicator to indicate that a full synchronization should be performed in response to detecting that a timer in the mobile terminal has been set back. Then, a full synchronization of the first database with the second database is performed if the indicator is set.
The indicator may be data dedicated to that purpose. However in alternative embodiments, setting the indicator may instead comprise changing a value of a database identifier. Since the database identifier will be communicated between the two databases anyway, no additional information needs to be communicated merely for the purpose of indicating that a full synchronization should be performed.
If the indicator is not set, a fast synchronization of the first database with the second database may instead be performed.
Moreover, if it is desired to establish a default synchronization technique, the indicator may be reset after performing the full synchronization of the first database with the second database.